1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for measuring round-trip latency to computing devices without requiring a client-side proxy presence.
2. Description of the Related Art
It is commonplace today for computer users to connect their machines to other computers, known as xe2x80x9cservers,xe2x80x9d through a network. The network may be a private network, such as a corporate intranet of networked computers that is accessible only to computer users within that corporation, or it may a public network, such as the Internet or World-Wide Web. The Internet is a vast collection of computing resources, interconnected as a network, from sites around the world. The World-Wide Web (referred to herein as the xe2x80x9cWebxe2x80x9d) is that portion of the Internet which uses the HyperText Transfer Protocol (xe2x80x9cHTTPxe2x80x9d) as a protocol for exchanging messages. (Alternatively, other protocols such as the xe2x80x9cHTTPSxe2x80x9d protocol can be used, where this protocol is a security-enhanced version of HTTP.)
The user working in a networked environment will have software running on his workstation to allow him to create and send requests for information to a server and to see the results. When the user connects to the Web, these functions are typically combined in software that is referred to as a xe2x80x9cWeb browser,xe2x80x9d or xe2x80x9cbrowser.xe2x80x9d After the user has created his request using the browser, the request message is sent out into the Internet for processing. The target of the request message is one of the interconnected servers in the Internet network. That server will receive the message, attempt to find the data satisfying the user""s request, format that data for display with the user""s browser, and return the formatted response to the browser software running on the user""s workstation. The response is typically in the form of a displayable file, referred to as a xe2x80x9cWeb pagexe2x80x9d, that may contain text, graphics, images, sound, video, etc.
These are examples of a client-server model of computing, where the machine at which the user requests information is referred to as the client, and the computer that locates the information and returns it to the client is the server. In the Web environment, the server is referred to as a xe2x80x9cWeb serverxe2x80x9d. The user may connect his computer to a server using a xe2x80x9cwirelinexe2x80x9d connection or a xe2x80x9cwirelessxe2x80x9d connection. Wireline connections are those that use physical media such as cables and telephone lines. Wireless connections, on the other hand, use media such as satellite links, radio frequency waves, and infrared waves. The user""s computer may be any type of computer processor, including laptop, hand held or mobile computers; vehicle-mounted devices; cellular telephones and desktop screen phones; desktop computers; mainframe computers; etc., having processing and communication capabilities. The remote server, similarly, can be one of any number of different types of computer which have processing and communication capabilities. The computer capabilities vary widely from high speed, multi-processors with extensive real and virtual memory, to small, single processors that process a single task with a limited function operating system and limited memory. These techniques are well known in the art, and the hardware devices and software which enable their use are readily available. Hereinafter, the user""s computer will be referred to as a xe2x80x9cworkstation,xe2x80x9d and use of the terms xe2x80x9cworkstationxe2x80x9d or xe2x80x9cserverxe2x80x9d refers to any of the types of computing devices described above.
As more people connect their workstations to the Web, the number of messages and files being sent is skyrocketing. (Hereinafter, the terms xe2x80x9cmessagexe2x80x9d and xe2x80x9cfilexe2x80x9d are used interchangeably when referring to data being sent through a network, unless otherwise stated.) Coupled with this increase in the number of network users and files is an increase in the size of the files commonly being sent. For example, a Web page may include one or more graphic images, each of which may consist of several hundred thousand bytes of data. Users may request many such files over the course of a day""s work, or in their personal network communications.
A great deal of user frustration can result when trying to access popular Web sites which must service an ever-increasing number of user requests, and which often have slow response times due to this heavy request load. Additionally, long delays may result when users request delivery of large files to their workstation (or even when requesting relatively small files from congested servers), creating yet more user frustration. The popularity of using portable computers such as handheld devices for connecting to the Internet, or other networks of computers, is increasing as user interest in computing becomes pervasive and users are more often working in mobile (i.e wireless) environments. At the same time, the popularity of making network connections using connection services that charge fees based upon the duration of connections (such as cellular services, which are commonly used for wireless connections from portable computers) is also growing. When using this type of relatively expensive connection, the longer the user must wait to receive a file, the higher his connection charges will be. Wireless connections also tend to have high network latencies, due to the limited bandwidth available and the extra network hops (e.g. gateways) that are involved with wireless transmission. As a result, a user may have to wait a relatively long time to receive a response to a request he has sent into the network. In addition, the capabilities of the client""s computer may limit the amount of data that can be received. These are some of the factors behind an increasing concern with optimizing performance of network computing environments.
One area of interest in network computing performance is the overall response time from the moment the client issues a request to a server until the server""s response is received by the client. This is known as the xe2x80x9cround tripxe2x80x9d time of a request/response message pair. A key component of the round trip time is the network latency. Network latency is the amount of time a message spends in the network and is a valuable measurement that can be used in a number of ways. (Round trip time also includes processing time at the server and any intermediate gateways. This processing time is not pertinent to the present invention. Hereinafter, the terms xe2x80x9cround trip timexe2x80x9d and xe2x80x9cnetwork latencyxe2x80x9d will be used interchangeably.) For example, the measured latency of a network can be analyzed to determine where bottlenecks occur. This analysis allows the network engineers to add or replace resources to reduce or eliminate a bottleneck, therefore improving overall response times by reducing network latency. Another value of measuring network latency is to use the latency information to dynamically determine the content of the information to be sent in response to a client request. For example, if a server receives a request for a Web page from a client over a network with very high latencies, it would be advantageous for the server to reduce or filter the amount of information sent in response to the client""s request. An example of the type of content reduction that could be used in this situation is applying a transcoding filter to transform color images into gray scale images, thereby drastically reducing the size of the response file and accordingly, the time it will take for this file to be transmitted to the client. In severe cases, more drastic forms of content reduction (such as eliminating video or image files completely) could be taken. Network latency information could also be combined with client-specific information, such as whether the client is connected over a relatively expensive wireless connection or a wireline connection, in making content-reduction choices.
This type of performance measurement in a network typically involves providing software that resides on the client machine. This software acts as a proxy or xe2x80x9cagentxe2x80x9d for the client and participates in capturing performance data for the network connection. This client-side software would typically have a counterpart on the server side of the communications (i.e. a xe2x80x9cserver-side proxyxe2x80x9d) that also participates in capturing performance information. This type of performance measuring technique therefore involves distributing the client and server measurement software to all clients and servers that are to be measured. However, this approach has a number of drawbacks. First, not all computers communicating on a network are capable of running the client-side software because of limitations such as operating system constraints (e.g. inability to support multi-tasking) and/or memory size that is so severely constrained as to make adding the measurement software impractical or even impossible. These limitations typically exclude the small, limited function computers that are so rapidly growing in popularity from being able to participate in the capture of performance data such as network latency information. In addition, the sheer volume and number of different types of client-side devices make it infeasible to use a technique that requires modifying (i.e. installing special software on) the client devices.
Accordingly, a need exists for a technique for measuring the latency of a network connection between a client and a server without requiring additional software on the client machine.
An object of the present invention is to provide a technique to measure network latency between a client and a server.
Another object of the present invention is to provide a technique to measure the network latency between a client and a server without requiring any client-side software.
It is yet another object of the present invention to provide this technique in a manner that does not require explicit participation or awareness of the user of the client computer.
It is another object of the present invention to enable a server application to gather network latency information to be used for optimizing communications between the client and the server.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a system, method, and program product for use in a computing environment having a connection to a network, for enabling collection of round-trip network latency measurements without requiring additional software on the client. In one aspect, this technique comprises: receiving a first client request for a first predetermined Uniform Resource Locator (URL); storing a first time at which the first client request was received; responding to the first client request with a redirection response, wherein the redirection response specifies a second predetermined URL; receiving a second client request for the second predetermined URL, wherein the second client request is received at a second time; computing a difference between the second time and the first time, wherein the difference represents a round trip latency between the client and the server; and sending, responsive to receiving the second client request, information associated with the first predetermined URL.
Preferably, the redirection response uses a page temporarily moved status code or a page permanently moved status code. The first predetermined URL may be a configurable parameter. Optionally, the first predetermined URL may be determined using a counter of requests received.
The server may be a server-side proxy server. In this case, the technique further comprises: forwarding the first client request to the server; and receiving, at the proxy server, a response to the forwarded request, wherein the response comprises the information associated with the first predetermined URL.
In another aspect, this technique comprises: receiving a first client request for a first predetermined Uniform Resource Locator (URL); storing a first time at which the first client request was received; responding to the first client request with a redirection response, wherein the redirection response specifies a second predetermined URL; receiving a second client request for the second predetermined URL, wherein the second client request is received at a second time; storing the second time for subsequent computation of a round trip latency between the client and the server, wherein the round trip latency is a difference between the second time and the first time; and sending, responsive to receiving the second client request, information associated with the first predetermined URL.